前端三分鐘 X 要轉職養豬還是做被取代的工程師？用 Google AI 打造我的 AI 雙刀流自動化工作流系列

在前面的文章裡，我們一路從 Rules ➔ Plugin ➔ Sidecar ➔ Subagent ➔ /command ➔ Plan，一步步把這座 AI 智慧豬場的藍圖給蓋了起來。

聽起來是不是超熱血？現在我們已經能讓 Agent 自動規劃、自動分工，甚至開始想像未來組成 Multi-Agent 團隊。

但這時候，一個極度現實且殘酷的工程問題浮現了：

「如果今天我直接把這些 Agent 塞進 Production 呢？」

例如：直接下指令：「去，把這 1,000 隻豬的資料全部改掉。」

相信我，今晚你大概不用睡覺了。XD

一、養豬第一原則：先養一隻試試看

真正有經驗的豬農，絕對不會一開始就：
買地 ➔ 蓋 1,000 頭豬舍 ➔ 買 1,000 隻豬 ➔ 開始祈禱 🙏

比較合理的做法是：先養一隻。

• 確認飼料配方對不對？
• 確認豬舍通風好不好？
• 確認這套養殖流程真的養得活？

AI 工作流（AI Workflow）也是完全一樣的道理。在把 Prompt、Tool、Agent Logic 全部硬編碼（Hard-code）進正式專案之前，我更喜歡先建立一座：「AI 實驗豬舍」。

而 Google AI Studio 就是最適合拿來做快速實驗與 Prototype 的沙盒環境。它不只是 Prompt Playground，現在的 Build Mode 更能透過自然語言快速建立 Full-stack Web App，即時檢視 Code 與預覽畫面。

  [ Google AI Studio (實驗豬舍) ]
                ↓
    實驗 Prompt / System Instructions
                ↓
    定義 JSON Schema / Structured Output
                ↓
    測試 Tool / Function Calling
                ↓
    驗證 Workflow 成功 (原型豬存活)
                ↓
  [ 搬進 Production 正式專案 (大規模養豬場) ]

二、第一階段：先讓 AI 講「固定格式」（Structured Output）

假設今天我們要打造一個「養豬場管理 Agent」，我問 Gemini：

「請分析 P001 這隻豬的狀態，並告訴我牠是否需要特別照護。」

如果讓 Gemini 自由發揮，我們可能會得到：

「P001 看起來狀況還不錯，不過體重稍微偏高，可以考慮注意一下飼料量。」

人類看得懂，但程式碼看了會崩潰。我們真正需要的不是「AI 跟我聊天」，而是**「AI 格式化地跟我的程式講話」**。

讓 AI 開始講 JSON

透過定義 Schema，我們可以強制 Gemini 回傳固定結構：

{
  "pig_id": "P001",
  "weight": 82,
  "health": "good",
  "needs_attention": false,
  "reason": "目前體重與健康狀態正常"
}

Gemini API 支援 JSON Schema，包含 object, array, string, number, boolean 等型別，也可設定 enum 與 required。

⚠️ 關鍵工程陷阱：Structured Output ≠ 內容絕對正確

請千萬記住這個核心原則：
Schema 正確 ≠ 資料內容正確

{
  "pig_id": "P001",
  "weight": 999,
  "health": "good"
}

這段 JSON 完全符合 Schema，但如果 P001 實際上只有 82kg，這隻豬已經在 JSON 裡被 AI 養爆了！ XD

真正的工程驗證防線應該是：
Gemini ➔ Structured Output ➔ Schema Validation ➔ Business Rule Validation ➔ 進入 Workflow

三、第二階段：AI 不只會講話，還要開始「叫工具」（Function Calling）

解決了「AI 如何跟程式說話」，下一個問題是：「AI 能不能真的動手做事情？」這就是 Function Calling。

  [ 使用者 ] ──> "幫我查 P001 最新體重"
                      ↓
                  [ Gemini ]
                      ↓ (判斷：需要查詢豬隻資料)
            [ Function Calling ]
                      ↓
           getPigWeight({ pig_id: "P001" })
                      ↓
             [ 你的應用程式 / DB ]
                      ↓
                    "82kg"
                      ↓ (交還資料)
                  [ Gemini ] ──> "P001 的最新體重為 82kg。"

觀念校正：Gemini 不會直接去連你的 Database。Gemini 負責「提出 Tool Call 請求」，真正執行資料庫查詢並拿回資料的，依然是你的 Application。

比較：Structured Output vs. Function Calling

四、串聯終極工作流：從實驗豬舍邁向軟體工廠

當我們把 Prompt + Structured Output + Function Calling + MCP 串聯起來，前面幾篇介紹的工具鏈就全部接通了：

  [ Prompt ] ──> 告訴 Agent 如何思考與決策
      │
  [ Structured Output ] ──> 規定 Agent 講話的資料格式
      │
  [ Function Calling ] ──> 讓 Agent 能夠發出動作請求
      │
  [ MCP (Model Context Protocol) ] ──> 提供標準化管道，存取 GitHub / DB / 豬場 Sensors
      │
  [ Subagent / Sidecar ] ──> 組成真正自動化的 Multi-Agent 豬場

🐷 我的 AI 雙刀流養豬 SOP

綜合上述實證，我整理出一套低風險的 AI 開發流程：

1. 需求模糊 ➔ 使用 /grill-me 釐清問題。
2. 架構規劃 ➔ 使用 /plan 產出實作計畫與驗證清單。
3. AI Studio 沙盒測試 ➔ 在「實驗豬舍」驗證 Prompt + Schema + Function Calling。
4. 驗證與防護網 ➔ 加入 Schema Validation & Business Rules。
5. 整合進 Codebase ➔ 結合 Gemini API + MCP + Agent。
6. 規模化展開 ➔ 啟用 Subagent + Multi-Agent 工作流。

結語：先把一隻豬養活，再談養一千隻

許多工程師剛接觸 AI Agent 時，一上來就堆疊各種炫砲詞彙：MCP！Subagent！Multi-Agent！Automation！

結果整個架構養了一大堆豬，最後沒有一隻真的活得下來。 XD

工程師最怕的從來不是「AI 不夠聰明」，而是AI 很聰明，但我一口氣給了牠 1,000 隻豬，結果全場失控。

先在 Google AI Studio 把原型豬養得健健康康，確定 Workflow 跑得通，再把它搬進 Production。

📝 本日實作作業：

今天請在 Google AI Studio 完成一個最小可行性 Prototype：

1. Step 1：建立 Prompt，要求 Gemini 分析一筆豬隻健康資料。
2. Step 2：設定 Structured Output（限制 health 為 good | warning | critical）。
3. Step 3：新增一個 Function getPigWeight(pig_id)。
4. Step 4：觀察 Gemini 發起 Tool Call ➔ 回傳結果 ➔ 產出結構化 JSON 的完整過程！

當這隻「原型豬」成功活下來，明天 Day 28，我們就把小豬機器人正式接回 Codebase，走進真正的智慧養豬場！🐷